1. Field of the Invention
The present invention relates to computer network management. More specifically, the present invention relates to a method and an apparatus that facilitates fast network management protocol replies in large tables.
2. Related Art
Network management database servers typically maintain tables related to network traffic. For example, a network management database server can maintain a table for transactions, which includes columns for a source Internet protocol (IP) address, a destination IP address, number of packets transmitted, and number of octets, or 8-bit bytes, transmitted. In general, the network management database server can maintain multiple tables, wherein each table includes columns for different sets of data.
An operator typically uses a network management protocol, for example simple network management protocol (SNMP) to access data within these tables. The operator first forms a request for the needed data at a console. This request is then passed to an agent within the network management database server. In many cases, the operator desires to repeatedly retrieve data from the next row in the table without knowing what that row is or where it is located. To facilitate this type of access, the network management protocol includes a method, called GetNext, to query the next row after a given row. In fact, GetNext can be used to access the first row within the table as well.
Consider Table I as an example. The operator can issue the following request from a console to access data in columns 1 and 2 of the first row:
GetNext OID(0,1) Val=0, OID(0,2) Val=0
where OID is the object identifier and Val is the value. In this request, the operator wants the value in column 1 of the row following row 0, OID(0,1)), and the value in column 2 of the row following row 0, (OID(0,2)).
This request is encoded in a protocol data unit (PDU). Upon receiving the request, the agent first decodes the OID within the PDU. Next, the agent searches for a matching OID in a management information base (MIB). The MIB is typically implemented as an ordered binary tree, and can be traversed using well-known techniques. After finding the matching OID in the MIB, the agent retrieves the requested data from the table. Next, the agent constructs an output PDU and encodes it with the requested data. Finally, the agent sends the output PDU to the requesting console. This output PDU includes OID(1,1) Val=TA(1,1), OID(1,2) Val=TA(1,2) indicating that the next row is row 1 and the values in columns 1 and 2 are TA(1,1) and TA(1,2) respectively.
As an additional example, consider Table 2. If the operator enters the following request at a console:
GetNext OID(99,4) Val=0, OID(99,2) Val=0,
The agent responds with OID(100,4) Val=TB(100,4), OID(100,2) Val=TB(100,2).
To summarize, when using GetNext, the agent responds with the data from the requested columns in the row following the identified row.
This procedure works well when the tables are small, however, as the tables grow larger, the time to locate the next item can become excessively long. Consider, for example, a table with 100,000 rows and an access time of 30 milliseconds per row. To search the table for the last item takes 300 seconds, with an average time over all items of 150 seconds. A delay of this length can degrade productivity and can cause frustration on the part of the operator.
What is needed is a method and an apparatus, which allows the operator to access the next row in very large tables while minimizing the delay described above.
One embodiment of the present invention provides a system that facilitates fast network management protocol replies in large tables. The system operates by first receiving a request for a next row from a network management protocol table. The system then compares the object identifier in the request with a pre-calculated object identifier. If the object identifier matches the pre-calculated object identifier, the system responds to the request with a pre-calculated response. If the object identifier does not match the pre-calculated object identifier, the system searches a management information base for the next row in the network management protocol table. Next, the system calculates a response, which includes data from requested columns of the next row. The system then responds to the request.
In one embodiment of the present invention, when the system receives a request for the next row from the network management protocol table, the system locates the protocol data unit in the request and determines the object identifier within the protocol data unit.
In one embodiment of the present invention, before responding to the request with either the pre-calculated response or with the newly calculated response, the system selects a candidate next row in the network management protocol table. The system then creates a pre-calculated object identifier for the candidate next row and saves the pre-calculated object identifier. The system also creates a pre-calculated response for the candidate next row, which includes data from requested columns of the candidate next row, and saves the pre-calculated response.
In one embodiment of the present invention, the system determines the next row in the network management protocol table by first decoding the object identifier in the protocol data unit. The system then searches for the object related to the object identifier in the management information base.
In one embodiment of the present invention, the request is one of a series of related requests.
In one embodiment of the present invention, saving the pre-calculated object identifier includes saving the pre-calculated object identifier in a table of pre-calculated object identifiers, so that pre-calculated object identifiers can be saved for more than one series of related requests.
In one embodiment of the present invention, saving the pre-calculated response includes saving the pre-calculated response in a table of pre-calculated responses, so that pre-calculated responses can be saved for more than one series of related requests.